Contract Aware Components, 10 years after

The notion of contract aware components has been published roughly ten years ago and is now becoming mainstream in several fields where the usage of software components is seen as critical. The goal of this paper is to survey domains such as Embedded Systems or Service Oriented Architecture where the notion of contract aware components has been influential. For each of these domains we briefly describe what has been done with this idea and we discuss the remaining challenges.Comment: In Proceedings WCSI 2010, arXiv:1010.233

Multilevel Contracts for Trusted Components

This article contributes to the design and the verification of trusted components and services. The contracts are declined at several levels to cover then different facets, such as component consistency, compatibility or correctness. The article introduces multilevel contracts and a design+verification process for handling and analysing these contracts in component models. The approach is implemented with the COSTO platform that supports the Kmelia component model. A case study illustrates the overall approach.Comment: In Proceedings WCSI 2010, arXiv:1010.233

Tau Be or not Tau Be? - A Perspective on Service Compatibility and Substitutability

One of the main open research issues in Service Oriented Computing is to propose automated techniques to analyse service interfaces. A first problem, called compatibility, aims at determining whether a set of services (two in this paper) can be composed together and interact with each other as expected. Another related problem is to check the substitutability of one service with another. These problems are especially difficult when behavioural descriptions (i.e., message calls and their ordering) are taken into account in service interfaces. Interfaces should capture as faithfully as possible the service behaviour to make their automated analysis possible while not exhibiting implementation details. In this position paper, we choose Labelled Transition Systems to specify the behavioural part of service interfaces. In particular, we show that internal behaviours (tau transitions) are necessary in these transition systems in order to detect subtle errors that may occur when composing a set of services together. We also show that tau transitions should be handled differently in the compatibility and substitutability problem: the former problem requires to check if the compatibility is preserved every time a tau transition is traversed in one interface, whereas the latter requires a precise analysis of tau branchings in order to make the substitution preserve the properties (e.g., a compatibility notion) which were ensured before replacement.Comment: In Proceedings WCSI 2010, arXiv:1010.233

Trust-Based Protection of Software Component Users and Designers

Abstract. Software component technology supports the cost-effective design of applications suited to the particular needs of the application owners. This design method, however, causes two new security risks. At first, a malicious component may attack the application incorporating it. At second, an application owner may incriminate a component designer falsely for any damage in his application which in reality was caused by somebody else. The first risk is addressed by security wrappers control-ling the behavior at the component interface at runtime and enforcing certain security policies in order to protect the other components of the application against attacks from the monitored component. Moreover, we use trust management to reduce the significant performance overhead of the security wrappers. Here, the kind and intensity of monitoring a com-ponent is adjusted according to the experience of other users with this component. Therefore a so-called trust information service collects posi-tive and negative experience reports of the component from various users

Simulation for training in sinus floor elevation : new surgical bench model

Objectives: to describe a bench model (workshop of abilities) for sinus floor elevation (SFE) training that simulates the surgical environment and to assess its effectiveness in terms of trainees? perception. Study design: thirty-six randomly selected postgraduate students entered this cross-sectional pilot study and asked to fill in an anonymous, self-applied, 12-item questionnaire about a SFE workshop that included a study guide containing the workshop?s details, supervised practice on a simulated surgical environment, and assessment by means of specific check-lists. Results: Thirtiy-six fresh sheep heads were prepared to allow access to the buccal vestible. Using the facial tuber, third premolar and a 3D-CT study as landmarks for trepanation, the sinus membrane was lifted, the space filled with ceramic material and closed with a resorbable membrane. The participants agreed on their ability to perform SFE in a simulated situation (median score= 4.5; range 2-5) and felt capable to teach the technique to other clinicians or to undertake the procedure for a patient under supervision of an expert surgeon (median= 4; range 1-5 ). There were no differences on their perceived ability to undertake the technique on a model or on a real patient under supervision of an expert surgeon (p=0.36). Conclusions: Clinical abilities workshops for SFE teaching are an essential educational tool but supervised clinical practice should always precede autonomous SFE on real patients. Simulation procedures (workshop of abilities) are perceived by the partakers as useful for the surgical practice. However, more studies are needed to validate the procedure and to address cognitive and communication skills, that are clearly integral parts of surgical performance

Enhancing Dependability of Component-based Systems

International audienceWe present a method to add dependability features to component-based software systems. The method is applicable if the dependability features add new behavior to the system, but do not change its basic functionality. The idea is to start with a software architecture whose central component is an application component that implements the behavior of the system in the normal case. The application component is connected to other components, possibly through adapters. It is then possible to enhance the system by adding dependability features in such a way that the central application component remains untouched. Adding dependability features necessitates to evolve the overall system architecture by replacing or newly introducing hardware or software components. The adapters contained in the initial software architecture have to be modified, whereas the other software components need not to be changed. Thus, the dependability of a component-based system can be enhanced in an incremental way

Specification of Business Components

Component-based software development is a potential reuse paradigm for the future. While the required technologies for a component-style system development are widely available, for instance Sun's Enterprise Java Beans, a problem inhibits the breakthrough of the component paradigm in business application domains: compared to traditional engineering disciplines there is a lack of standardized methods to describe business components. Such a description has to address several aspects: What services are offered and requested by a business component? How can these services be used? Are there any interdependencies between the services of a set of business components? What quality characteristics do the offered services fulfill? And so on. In this paper, we present a holistic approach to specify a business component. This approach consists of seven specification levels which address both technical and business aspects. Furthermore, we show the application of this method by specifying a simple business component that deals with German bank codes

A Risk-Return Comparison of Retained Ownership Programs Using Alternative Hedging and Pricing Strategies

We discuss Web Service Management (WSM) and Web Service Composition Management (WSCM) applications of the Web Service Offerings Language (WSOL) and how the language supports these applications. WSOL is a language for the formal specification of classes of service, various constraints (functional constraints, Quality of Service—QoS, and access rights), and management statements (prices, monetary penalties, and management responsibilities) for Web Services. Describing a Web Service in WSOL, in addition to the Web Services Description Language, enables monitoring, metering, accounting, and management of Web Services. Metering of QoS metrics and evaluation of constraints can be the responsibility of the provider Web Service, the consumer, and/or one or more mutually trusted third parties (SOAP intermediaries or probes). Further, manipulation (switching, deactivation, reactivation, deletion, or creation) of classes of service can be used for dynamic (run-time) adaptation and management of Web Service compositions. To demonstrate the usefulness of WSOL for WSM and WSCM, we have developed a corresponding management infrastructure, the Web Service Offerings Infrastructure (WSOI). WSOI enables monitoring of WSOLenable